I work on code review, automated tests and BDD to reduce bugs, ambiguity in requirements and the gap between what is estimated and what actually happens. I am Luca Lucchesi, an independent Code Quality consultant, and I work with companies with at least 20 developers overall, even when they are distributed across several teams.
I do not sell tools. I sell visible improvements in code quality and in the team’s day-to-day work. To avoid fragmented interventions, I work in phases: understand the situation, decide what matters, put guardrails where they are needed, and make the team autonomous. Durations are indicative and depend on volume and complexity.
A technical, concrete snapshot: where the hotspots are, where risk is growing, what makes sense to do now (and what does not).
Typical duration: 2–3 weeks.
We turn the assessment into a sustainable roadmap: guidelines, a realistic test strategy, useful metrics and coherent technical choices.
Typical duration: 1–2 months.
Temporary support on the most critical pull requests: preventing regressions and consolidating shared practices and criteria, without turning review into a bottleneck.
Typical duration: 1–2 months (time-boxed, with an explicit goal).
Practical support to make the team autonomous: in-line coaching, targeted workshops and improvements that remain after the consulting work is over.
Typical duration: 2–3 months (optional).
These are the main areas I work on. They usually come into play in one or more phases of the path, depending on where the codebase and workflows show bottlenecks.
Analysis of repositories, project structure, internal conventions, branch model and code review practices.
Understanding where the flow gets stuck is the first step toward making it move.
Design or review of automated test suites, with attention to reliability, execution times, long-term maintainability and coverage of critical cases.
Tests that create confidence, not false alarms.
Targeted interventions on builds and pipelines only when they are a bottleneck (slowness, instability, flaky tests). The goal is not to “do DevOps”, but to remove impediments that slow development and release.
Less waiting, fewer breakages, more continuity.
Introduction or review of quality rules and controls (e.g. Checkstyle, SpotBugs, PMD) that can be integrated into builds. If a more complete layer of analysis and governance is needed, we can also evaluate solutions such as SonarQube together.
The simplest way to make informed decisions.
Pragmatic training on refactoring, effective code reviews, TDD when it makes sense and BDD: defining scenarios during refinement and translating them into automated tests, to verify that the system really satisfies the expected behaviours.
First we write examples, then we write software.
We can start from a limited analysis (one project, one pipeline, one test suite) and then extend the work based on results and priorities.
Starting small is often the best way to see immediately where it makes sense to invest.
I do not start from zero and I do not come in to do abstract evangelism. I work best with organizations that already have solid developers and existing infrastructure, but feel that quality can (and should) improve.
If you recognize yourself in at least two of these points, I can probably help.
I do not judge. I work to make the flow simpler and more predictable: less friction, more confidence, more quality.
Every engagement follows a clear structure. The details depend on the context, but the method remains the same: understand the situation, intervene in a targeted way, consolidate the results.
In the first call, I can show you a sample roadmap based on a real case (in anonymized form).
If after the analysis phase I understand that I am not the right person to help you, I tell you clearly.
I have spent many years writing code, reviewing it, debugging, designing pipelines and helping teams work better. This is the point of view I bring as a consultant.
“I am a consultant, not a salesperson: if I cannot help you, I would rather tell you straight away than promise results I cannot guarantee.”
The examples below come from real experience. The contexts have been anonymized, but the results are ones I can explain and argue in detail.
During a first conversation I can go into more detail on these examples, adapting them to your specific context.
Some questions I often receive when companies are evaluating whether to start a collaboration.
If you recognize yourself in the problems described above, the next step is to talk about your specific context. No long-term commitment: first we understand whether it makes sense to work together.
